1. Field of the Invention
This invention relates generally to the field of data processing systems. More particularly, the invention relates to a system and method for implementing multiple application server clusters using a common binary directory structure.
2. Description of the Related Art
Multi-Tiered Enterprise Software
Traditional client-server systems employ a two-tiered architecture such as that illustrated in FIG. 1a. Applications 102 executed on the client side 100 of the two-tiered architecture are comprised of a monolithic set of program code including a graphical user interface component, presentation logic, business logic and a network interface that enables the client 100 to communicate over a network 103 with one or more servers 101. A database 104 maintained on the server 101 provides non-volatile storage for the data accessed and/or processed by the application 102.
As is known in the art, the “business logic” component of the application represents the core of the application, i.e., the rules governing the underlying business process (or other functionality) provided by the application. The “presentation logic” describes the specific manner in which the results of the business logic are formatted for display on the user interface. The “database” 104 includes data access logic used by the business logic to store and retrieve data.
The limitations of the two-tiered architecture illustrated in FIG. 1a become apparent when employed within a large enterprise. For example, installing and maintaining up-to-date client-side applications on a large number of different clients is a difficult task, even with the aid of automated administration tools. Moreover, a tight coupling of business logic, presentation logic and the user interface logic makes the client-side code very brittle. Changing the client-side user interface of such applications is extremely hard without breaking the business logic, and vice versa. This problem is aggravated by the fact that, in a dynamic enterprise environment, the business logic may be changed frequently in response to changing business rules. Accordingly, the two-tiered architecture is an inefficient solution for enterprise systems.
In response to limitations associated with the two-tiered client-server architecture, a multi-tiered architecture has been developed, as illustrated in FIG. 1b. In the multi-tiered system, the presentation logic 121, business logic 122 and database 123 are logically separated from the user interface 120 of the application. These layers are moved off of the client 125 to one or more dedicated servers on the network 103. For example, the presentation logic 121, the business logic 122, and the database 123 may each be maintained on separate servers, 126, 127 and 128, respectively.
This separation of logic components and the user interface provides a more flexible and scalable architecture compared to that provided by the two-tier model. For example, the separation ensures that all clients 125 share a single implementation of business logic 122. If business rules change, changing the current implementation of business logic 122 to a new version may not require updating any client-side program code. In addition, presentation logic 121 may be provided which generates code for a variety of different user interfaces 120, which may be standard browsers such as Internet Explorer® or Netscape Navigator®.
The multi-tiered architecture illustrated in FIG. 1b may be implemented using a variety of different application technologies at each of the layers of the multi-tier architecture, including those based on the Java 2 Enterprise Edition™ (“J2EE”) standard, the Microsoft .NET standard and/or the Advanced Business Application Programming (“ABAP”) standard developed by SAP AG. For example, in a J2EE environment, the business layer 122, which handles the core business logic of the application, is comprised of Enterprise Java Bean (“EJB”) components with support for EJB containers. Within a J2EE environment, the presentation layer 121 is responsible for generating servlets and Java Server Pages (“JSP”) interpretable by different types of browsers at the user interface layer 120.
An Exemplary Application Server Platform
The assignee of the present application has developed a clustered server platform for implementing a J2EE architecture. As illustrated in FIG. 2, the architecture includes a central services instance 200 and a plurality of application server instances 210, 220. As used herein, the application server instances, 210 and 220, each include a group of application servers 214, 216, 218 and 224, 226, 228, respectively, and a dispatcher, 212, 222, respectively. The central services instance 200 includes a locking service 202 and a messaging service 204 (described below). The combination of all of the application instances 210, 220 and the central services instance 200 is referred to herein as a “cluster.” Although the following description will focus solely on instance 210 for the purpose of explanation, the same principles apply to other instances such as instance 220.
The application servers 214, 216, 218 within instance 210 provide the business and/or presentation logic for the network applications supported by the system. Each of the application servers 214, 216, 218 within a particular instance 210 may be configured with a redundant set of application logic and associated data. In one embodiment, the dispatcher 210 distributes service requests from clients to one or more of the application servers 214, 216, 218 based on the load on each of the servers.
The application servers 214, 216, 218 may be Java 2 Enterprise Edition (“J2EE”) application servers which support Enterprise Java Bean (“EJB”) components and EJB containers (at the business layer) and Servlets and Java Server Pages (“JSP”) (at the presentation layer). Of course, the embodiments of the invention described herein may be implemented in the context of various different software platforms including, by way of example, Microsoft .NET platforms and/or the Advanced Business Application Programming (“ABAP”) platforms developed by SAP AG, the assignee of the present application.
In one embodiment, communication and synchronization between each of the instances 210, 220 is enabled via the central services instance 200. As illustrated in FIG. 2, the central services instance 200 includes a messaging service 204 and a locking service 202. The message service 204 allows each of the servers within each of the instances to communicate with one another via a message passing protocol. For example, messages from one server may be broadcast to all other servers within the cluster via the messaging service 204 (e.g., such as the cache configuration messages described below). Alternatively, messages may be addressed directly to specific servers within the cluster (i.e., rather than being broadcast to all servers).
The locking service 202 disables access to (i.e., locks) certain specified portions of configuration data and/or program code stored within a central database 230. The locking manager locks data on behalf of various system components which need to synchronize access to specific types of data and program code (e.g., such as the configuration managers 244, 254 illustrated in FIG. 2). As described in detail below, the locking service enables a distributed caching architecture for caching copies of server/dispatcher configuration data.
As illustrated in FIG. 2, each application server (e.g., 218, 228) includes a lock manager 240, 250 for communicating with the locking service 202; a cluster manager 242, 252 for communicating with the messaging service 204; and a configuration manager 244, 254 for communicating with a central database 230 (e.g., to store/retrieve configuration data as described herein).
Referring now to FIG. 3, the configuration data and binaries 320 defining the configuration of each of the instances 210 and 220, is stored within the central database 230. The configuration data and binaries define the kernel, services, libraries, and interfaces employed on each dispatcher and server (and various other types of information related to the cluster).
As illustrated in FIG. 3, in one embodiment, a hierarchical directory structure is used to organize and manage the different types of configuration data and binaries employed within the cluster. At the root of the hierarchy is the “cluster data” object 300. In one embodiment, the cluster data object 300 includes bootstrap object 310 for storing bootstrap binaries and configuration parameters; a dispatcher object 320 for storing configuration data and binaries for each dispatcher within the cluster; and a plurality of individual server objects 330, 340 for storing configuration data and binaries for each individual server node. A separate binaries (“bin”) directory 332 and 342, respectively, is provided under each server object 330 and 340, respectively. In addition, a separate bin directory 321 is also provided under each dispatcher object 320 within the hierarchy.
As indicated in FIG. 3, when the cluster is started up, bootstrap logic 350 reads the binaries and configuration data 360 from the central database 230 and synchronizes the binaries and configuration data with the file system of each individual instance. During this process, separate bootstrap processes 351-353 synchronize separate sets of binary files (e.g., .jar files in a Java environment) to the various bin directories within the file system of each instance. A separate group of classloaders then load the binaries on each server node and dispatcher. The Java class loading mechanism is well known and is described in the paper Dynamic Class Loading in the Java Virtual Machine, by Sheng Liang and Gilad Bracha, published in the proceedings of the ACM conference on Object Oriented Programming Systems, Languages and Applications (1998).
The foregoing configuration is inefficient for a variety of reasons. First, storing a separate set of binary data within a separate /bin directory for each server node within the cluster consumes an unreasonable amount of storage space, particularly given the fact that many of the binary files are the same. Moreover, a significant amount of network bandwidth is consumed as each set of binary files are transferred separately from the common database 230. In addition, a significant amount of processing power is consumed as each set of binaries are separately loaded into memory on each individual server using a separate class loader. Accordingly, what is needed is a more efficient mechanism for managing binary files for a cluster of server nodes.